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Introduction 


Software  Failure  Modes,  Effects,  and  Criticality 
Analysis  Special  Assessment  Procedure 
(FMASAP:1-1)  is  one  of  the  16  Procedures  that 
make  up  the  SED  Software  Engineering 
Evaluation  System  (SEES). 


Note:  For  information  concerning  the  other  15  SEES 
procedures,  contact: 
jackie.langhout@sed.redstone.amiy.mil 


256-876-3038 


Introduction  (Cont’d) 


FMASAP  is  applicable  to  Systems  which  possess 
one  or  more  of  the  following  characteristics: 

-  Fault  Tolerant 

-  Safety-Critical 

-  Embedded 


Real-time 


Introduction  (Cont’d) 


Purpose  of  FMASAP  is  to  determine: 

-  Potential  system  failures  and  criticality. 

-  Root  causes  for  critical  hardware  and  interface  failures. 

-  Software  resilience  to  hardware  interface  anomalies. 

-  Operational  impacts  of  software  responses  to  hardware 
failures. 


Note:  FMASAP  is  not  intended  to  address  software-to- 
software  interfaces,  but  could  be  tailored  to  address 
them  in  concert  with  Fault  Tree  Analysis. 


Introduction  (Cont’d) 

•  FMASAP  is  recommended  to  be  performed  at 
PDR,  CDR,  and  completion  of  CUT. 

•  When  System  Modes  exist,  perform  the  FMASAP 
procedures  as  a  separate  set  of  analyses  (i.e.,  each 
System  mode  requires  a  unique  set  of  RRLF  and 
SFMECAF  forms). 


Note:  It  is  recommended  the  FMASAP  be  performed  on  a 

continuing  basis  to  ensure  accurate  results  at  the  end  of 
the  development  and  to  address  approved  Engineering 
Change  Proposals. 


Introduction  (Cont’d) 


FMA  identifies  Single  Point  interface  failures 
only.  To  address  Multiple  Point  interface  failures, 
extend  the  Single  Point  FMA  analysis  by 

identifying  the  multiple  interfaces. 


Introduction  (Cont’d) 
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Figure  1-1  Software  Failure  Modes,  Effects,  and  Criticality  Analysis  SAP  Flow  Chart 
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TASK  1 

Determine  Failure  Analysis 
Need  and  Scope 

Purpose:  Scope  (Delimit)  the  analysis: 

-  Specify  System  Reliability,  Fault  Tolerant,  and  Safety 
requirements  and  policies. 

-  Specify  associated  hardware  interfaces. 


Identify  associated  software  to  be  analyzed. 


TASK  1 

Determine  Failure  Analysis 
Need  and  Scope  (Cont’d) 

Determine  resilience  of  software  design  to 
accommodate  discrete  hardware  interface 
anomalies  including: 

-  Continuous  input  signals  due  to  electrical  shorts. 

-  Single  event  upsets. 

-  Intermittent  operations. 

-  Input  Buffer  overflow. 

-  Lost  interrupts/control  signals. 

-  Defective  Direct  Memory  Access  operations. 

-  Defective  clocks  and  timers. 

-  Transmission  Errors/Device  Inoperability. 


TASK  1 

Determine  Failure  Analysis 
Need  and  Scope  (Cont’d) 

Step  1 :  Determine  the  System/Software 

Reliability,  Fault  Tolerant,  &  Safety 
Requirements/Policy  (Col.  1,  2,  &  3) 

•  Data  information  sources  include: 

-  System  Specification. 

-  Project/Program  Policies  &  SOW. 

-  System  Interface  Control  Documents. 

-  Interface  Requirements  Specifications  (IRSs). 

-  System/Segment  Design  Document  (SSDD). 

-  Subsystem  Design  Documents. 


r 


SEES  Reliability  Requirements  List  Form  (RRLF) 


~\ 


Item  No. 
Col.  1 

Requirement/Policy  Document  Name  and  Identifier 

Col.  2 

Req./Policy  Identifier 
Col.  3 

Name  of  Interface  Implicated 
Col.  4 

Comment 
Col.  5 

1 

Missile  Guidance  System  Segment  Design  Document  -  Ml 05004-1 

3.1.4 

Missile  Position  Data  Buffer 

Missile  System  Interface  Requirements  Document  -  Ml 0501 2-0 

3.2.6 

Missile  Position  Data  Buffer 

2 

Weapons  Carrier  System  Spec  -  Ml 05006-0 

3.3 

Weapons  Platform 

Weapons  Platform  Interface  Spec.  -  Ml 0500 13-0 

3.3 

Articulation  Driver  Input 

N 
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Figure  2-1 
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TASK  1 

Determine  Failure  Analysis  Need 

and  Scope  (Cont’d) 

Step  2:  Specify  the  hardware  interface  involved 
(Col.  4). 

Step  3:  Identify  associated  software  subsystem/CSCI 
(Col.5). 


Note:  Task  1  can  be  skipped  if  specific  or  all 

hardware/software  interfaces  are  to  be  analyzed. 


12 


TASKs  2-5 
Complete  SFMECAF 


•  RRLF  entries  scope  areas  needing  analysis. 

•  The  Software  Failure  Modes,  Effects  and 
Criticality  Analysis  Form  (SFMECAF)  documents 
the  analysis. 

•  The  SFMECAF  has  an  entry  for  each  RRLF  entry 
that  has  software  associated  with  it. 

•  SFMECAF  Column  1  correlates  directly  to  the 
RRLF  Column  1. 


13 


— - — - V 

SEES  Software  Failure  Modes,  Effects,  and  Criticality  Analysis  Form  (SFMECAF) 


Program  ID  Sure  shot  Missile 
Technical  Lead  Amcom 


Analysis  Date: 
System: - 


3/1/96 


Missile  Guidance 


RRLF 

Item  No. 

Interface 

Data 

System 

Hardware 

Interface 

Software 

Element 

System 
Failure  Modes 

Effects 

Criticality 

Comments/Rec. 
Sw/Hw  Changes 

Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

Col.  7 

Col.  8 

1 

a.  Position 

a.  Radar  Input 

a.  Missile  CSCI 

t.  No  Data 

1.  No  Nav.  command  updates 

1  Catastropic 

1  Use  backup  system 

Coordinates 

Buffer 

2.  Data 

2.  Erratic  cmds.  generated  and 

2.  Critical 

inputs  after  checking  if 

b.  Time 

b.  Radar  Input 

b  Missile  CSCI 

Inconsistant 

operator  error  message 

■nissile  position  data  is 

Buffer 

with  Missile 

reasonable  and  available. 

Status 

2.  (Same  as  1  above.) 

3.  Irregular  data 

3.  Erratic  Nav.  cmds.  and 

3.  Critical 

3.  Implement  dead 

values  (out  of 

reckon  algorithm  and/ 

reasonableness 

or  use  backup  system 

range) 

missile  position  data. 

4.  Input  timing 

4.  Missile  guidance  precision 

4.  Marginal 

4.  (Same  as  3  above.) 

incorrect 

loss 

2 

a.  Angle  and 

a.  Platform  Input 

a  Platform 

1.  No  Data 

1.  No  positioning  and  Weapon 

1.  Critical 

1.  Run  Diagnostics 

Azimuth  Data 

Registers 

Articulation  CSCI 

not  fired 

Reset  System 

2.  Data  inconsistant 

2.  Weapon  not  fired 

2  Critical 

2.  Restart  System 

with  Platform  status 

3.  Unreasonable 

3.  Incorrect  Platform/Weapon 

3.  Catastrophic 

3.  Verify  data  for 

Data 

aiming 

reasonableness 

N 

Page  of 


SEES-SFMECAF.1  Sept '96  Figure  3-1 


Multiple  Point  Interface  Failures 


FMA  identifies  Single  Point  interface  failures 
only.  To  address  Multiple  Point  interface  failures, 
extend  the  Single  Point  FMA  analysis  by 
identifying  the  multiple  interfaces  in  SFMECAF 
columns  1  through  4  and  treating  each  multiple 
interface  as  a  single  entry  by  completing  the 
analysis  in  columns  5  through  8. 


TASK  2 

Identify  Each  Software  Element 

to  be  Analyzed 


•  Minimize  analysis  effort  by: 

•  Focusing  on  a  small  subset  of  software  elements 
involved  in  the  actual  processing  and  affecting 
the  correctness  of  the  hardware  interfaces  input 
data. 


16 


TASK  2 

Identify  Each  Software  Element 
to  be  Analyzed  (Cont’d) 

Step  1 :  Identify  System  Input  Data  and  Hardware 
Devices 

a.  Enter  on  the  SFMECAF  the  RRLF  Item  No. 
(from  Col.  1)  being  analyzed. 

b.  For  each  entry  specify  the  type  of  interface  data 

(Col.  2)  and  discrete  hardware  interface  (Col.  3). 

Step  2:  Specify  the  Software  Elements  that  process  the 
Discrete  Hardware  Interface  Data  (Col.  4). 


17 


— - — - V 

SEES  Software  Failure  Modes,  Effects,  and  Criticality  Analysis  Form  (SFMECAF) 


Program  ID  Sure  shot  Missile 
Technical  Lead  Amcom 


Analysis  Date: 
System: - 


3/1/96 


Missile  Guidance 


RRLF 

Item  No. 

Interface 

Data 

System 

Hardware 

Interface 

Software 

Element 

System 
Failure  Modes 

Effects 

Criticality 

Comments/Rec. 
Sw/Hw  Changes 

Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

Col.  7 

Col.  8 

1 

a.  Position 

a.  Radar  Input 

a.  Missile  CSCI 

t.  No  Data 

1.  No  Nav.  command  updates 

1  Catastropic 

1  Use  backup  system 

Coordinates 

Buffer 

2.  Data 

2.  Erratic  cmds.  generated  and 

2.  Critical 

inputs  after  checking  if 

b.  Time 

b.  Radar  Input 

b  Missile  CSCI 

Inconsistant 

operator  error  message 

■nissile  position  data  is 

Buffer 

with  Missile 

reasonable  and  available. 

Status 

2.  (Same  as  1  above.) 

3.  Irregular  data 

3.  Erratic  Nav.  cmds.  and 

3.  Critical 

3.  Implement  dead 

values  (out  of 

reckon  algorithm  and/ 

reasonableness 

or  use  backup  system 

range) 

missile  position  data. 

4.  Input  timing 

4.  Missile  guidance  precision 

4.  Marginal 

4.  (Same  as  3  above.) 

incorrect 

loss 

2 

a.  Angle  and 

a.  Platform  Input 

a  Platform 

1.  No  Data 

1.  No  positioning  and  Weapon 

1.  Critical 

1.  Run  Diagnostics 

Azimuth  Data 

Registers 

Articulation  CSCI 

not  fired 

Reset  System 

2.  Data  inconsistant 

2.  Weapon  not  fired 

2  Critical 

2.  Restart  System 

with  Platform  status 

3.  Unreasonable 

3.  Incorrect  Platform/Weapon 

3.  Catastrophic 

3.  Verify  data  for 

Data 

aiming 

reasonableness 

N 
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SEES-SFMECAF.1  Sept '96  Figure  3-1 


TASK  3 

Specify  Failure  Modes 


•  Identify  each  possible  result  of  the  hardware 
interface  failure  (Col.  5),  for  example: 

•  Intermittent  Data. 

•  Buffer  overflow. 

•  Lost  or  overwritten  corrupted  input  data. 

•  No  Data. 

•  Defective  time. 

•  Incorrect  error  detection  (CRCs,  checksums). 

•  Inconsistent  Data. 


19 


TASK  3 

Specify  Failure  Modes  (Cont’d) 


•  Column  5  data  is  based  upon  Column  2,  3,  and  4, 
but  may  have  more  or  less  items. 

•  Permits  the  determination  of: 

•  Criticality. 

•  Possible  corrective  action. 

•  Testing  approaches. 


20 


— - — - V 

SEES  Software  Failure  Modes,  Effects,  and  Criticality  Analysis  Form  (SFMECAF) 


Program  ID  Sure  shot  Missile 
Technical  Lead  Amcom 


Analysis  Date: 
System: - 


3/1/96 


Missile  Guidance 


RRLF 

Item  No. 

Interface 

Data 

System 

Hardware 

Interface 

Software 

Element 

System 
Failure  Modes 

Effects 

Criticality 

Comments/Rec. 
Sw/Hw  Changes 

Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

Col.  7 

Col.  8 

1 

a.  Position 

a.  Radar  Input 

a.  Missile  CSCI 

t.  No  Data 

1.  No  Nav.  command  updates 

1  Catastropic 

1  Use  backup  system 

Coordinates 

Buffer 

2.  Data 

2.  Erratic  cmds.  generated  and 

2.  Critical 

inputs  after  checking  if 

b.  Time 

b.  Radar  Input 

b  Missile  CSCI 

Inconsistant 

operator  error  message 

■nissile  position  data  is 

Buffer 

with  Missile 

reasonable  and  available. 

Status 

2.  (Same  as  1  above.) 

3.  Irregular  data 

3.  Erratic  Nav.  cmds.  and 

3.  Critical 

3.  Implement  dead 

values  (out  of 

reckon  algorithm  and/ 

reasonableness 

or  use  backup  system 

range) 

missile  position  data. 

4.  Input  timing 

4.  Missile  guidance  precision 

4.  Marginal 

4.  (Same  as  3  above.) 

incorrect 

loss 

2 

a.  Angle  and 

a.  Platform  Input 

a  Platform 

1.  No  Data 

1.  No  positioning  and  Weapon 

1.  Critical 

1.  Run  Diagnostics 

Azimuth  Data 

Registers 

Articulation  CSCI 

not  fired 

Reset  System 

2.  Data  inconsistant 

2.  Weapon  not  fired 

2  Critical 

2.  Restart  System 

with  Platform  status 

3.  Unreasonable 

3.  Incorrect  Platform/Weapon 

3.  Catastrophic 

3.  Verify  data  for 

Data 

aiming 

reasonableness 

N 
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SEES-SFMECAF.1  Sept '96  Figure  3-1 


TASK  4 

Postulate  Failure  Modes  Effects 


•  Review  design  at  lowest  level  available. 

•  Preliminary  Design. 

•  Critical  Design. 

•  Source  Code. 

•  Specify  effect  on  software  when  failure  mode  being 
analyzed  occurs  (Col.  6). 

•  For  each  Column  5  item,  there  should  be  a  Column 
6  item. 
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— - — - V 

SEES  Software  Failure  Modes,  Effects,  and  Criticality  Analysis  Form  (SFMECAF) 


Program  ID  Sure  shot  Missile 
Technical  Lead  Amcom 


Analysis  Date: 
System: - 


3/1/96 


Missile  Guidance 


RRLF 

Item  No. 

Interface 

Data 

System 

Hardware 

Interface 

Software 

Element 

System 
Failure  Modes 

Effects 

Criticality 

Comments/Rec. 
Sw/Hw  Changes 

Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

Col.  7 

Col.  8 

1 

a.  Position 

a.  Radar  Input 

a.  Missile  CSCI 

t.  No  Data 

1.  No  Nav.  command  updates 

1  Catastropic 

1  Use  backup  system 

Coordinates 

Buffer 

2.  Data 

2.  Erratic  cmds.  generated  and 

2.  Critical 

inputs  after  checking  if 

b.  Time 

b.  Radar  Input 

b  Missile  CSCI 

Inconsistant 

operator  error  message 

■nissile  position  data  is 

Buffer 

with  Missile 

reasonable  and  available. 

Status 

2.  (Same  as  1  above.) 

3.  Irregular  data 

3.  Erratic  Nav.  cmds.  and 

3.  Critical 

3.  Implement  dead 

values  (out  of 

reckon  algorithm  and/ 

reasonableness 

or  use  backup  system 

range) 

missile  position  data. 

4.  Input  timing 

4.  Missile  guidance  precision 

4.  Marginal 

4.  (Same  as  3  above.) 

incorrect 

loss 

2 

a.  Angle  and 

a.  Platform  Input 

a  Platform 

1.  No  Data 

1.  No  positioning  and  Weapon 

1.  Critical 

1.  Run  Diagnostics 

Azimuth  Data 

Registers 

Articulation  CSCI 

not  fired 

Reset  System 

2.  Data  inconsistant 

2.  Weapon  not  fired 

2  Critical 

2.  Restart  System 

with  Platform  status 

3.  Unreasonable 

3.  Incorrect  Platform/Weapon 

3.  Catastrophic 

3.  Verify  data  for 

Data 

aiming 

reasonableness 

N 
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SEES-SFMECAF.1  Sept '96  Figure  3-1 


TASK  5 

Assign  Failure  Modes  Effects 
Criticality/  S  e  verity 

Specify  in  Column  7  the  criticality/severity  of  each 
failure  effect  item  in  Column  6.  For  software  design 
that  accommodates  the  anomaly,  the  state  specified 
in  Column  7  is  (NONE). 

There  should  be  an  item  in  Column  7  for  each  item 
in  Column  6. 

States  of  Criticality:  Severity  Classifications  per 
1629A,  4.4.3,  i.e.,  Category  I,  II,  III,  IV,  and  None. 

Column  8  is  optional. 


— - — - V 

SEES  Software  Failure  Modes,  Effects,  and  Criticality  Analysis  Form  (SFMECAF) 


Program  ID  Sure  shot  Missile 
Technical  Lead  Amcom 


Analysis  Date: 
System: - 


3/1/96 


Missile  Guidance 


RRLF 

Item  No. 

Interface 

Data 

System 

Hardware 

Interface 

Software 

Element 

System 
Failure  Modes 

Effects 

Criticality 

Comments/Rec. 
Sw/Hw  Changes 

Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

Col.  7 

Col.  8 

1 

a.  Position 

a.  Radar  Input 

a.  Missile  CSCI 

t.  No  Data 

1.  No  Nav.  command  updates 

1  Catastropic 

1  Use  backup  system 

Coordinates 

Buffer 

2.  Data 

2.  Erratic  cmds.  generated  and 

2.  Critical 

inputs  after  checking  if 

b.  Time 

b.  Radar  Input 

b  Missile  CSCI 

Inconsistant 

operator  error  message 

■nissile  position  data  is 

Buffer 

with  Missile 

reasonable  and  available. 

Status 

2.  (Same  as  1  above.) 

3.  Irregular  data 

3.  Erratic  Nav.  cmds.  and 

3.  Critical 

3.  Implement  dead 

values  (out  of 

reckon  algorithm  and/ 

reasonableness 

or  use  backup  system 

range) 

missile  position  data. 

4.  Input  timing 

4.  Missile  guidance  precision 

4.  Marginal 

4.  (Same  as  3  above.) 

incorrect 

loss 

2 

a.  Angle  and 

a.  Platform  Input 

a  Platform 

1.  No  Data 

1.  No  positioning  and  Weapon 

1.  Critical 

1.  Run  Diagnostics 

Azimuth  Data 

Registers 

Articulation  CSCI 

not  fired 

Reset  System 

2.  Data  inconsistant 

2.  Weapon  not  fired 

2  Critical 

2.  Restart  System 

with  Platform  status 

3.  Unreasonable 

3.  Incorrect  Platform/Weapon 

3.  Catastrophic 

3.  Verify  data  for 

Data 

aiming 

reasonableness 

N 
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SEES-SFMECAF.1  Sept '96  Figure  3-1 


Metrics 


Failure  Mode  Deficiencies  by 
Criticality  for  each  Software 
Design  Element 


Software  Design 

Criticality/Severity 

Element 

(CSCI,  CSU,  etc.) 

1 

II 

III 

IV 

Effort  Planning  Data 


Assumption:  A  CSCI  has  100-150  requirements  in  SRS 

and  has  3  to  6  hardware  interfaces. 


Per  CSCI 

Task  1 

Determine  Failure  Analysis 

Need  and  Scope 

5-10 

Days 

Task  2 

Identify  Each  Software  Element 
or  Component  to  be  Analyzed 

3-10 

Days 

Task  3 

Specify  Failure  Modes 

2-5 

Days 

Task  4 

Postulate  Failure  Modes  Effects 

5-10 

Days 

Task  5 

Assign  Failure  Modes  Effects 
Criticality/ S  e  verity 

2-5 

Days 

Software  Failure  Modes,  Effects,  and  Criticality  Analysis  Form  (SFMECAF) 


RRLF 

Item 

No. 

Interface 

Data 

System 

Hdwe. 

Interface 

Software 

Element 

System 

Failure 

Modes 

Effects/ 

Detection 

Method 

Criti 

calit 

y 

Rec. 

SW/HW 

Changes 

Mitigating 

Design 

Feature/ 

Alternate 

Operating 

Procedure 

Mitigating 

Design 

Feature 

Failure 

Detection 

Mitigating 

Tests/ 

Inspections 

Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.5 

Col.  6 

Col. 

7 

Col.  8 

Col.  9 

Col.  10 
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